Shipping Software
A few weeks ago I had lunch with the now famous "Mark Jen". I never knew Mark while we were at Microsoft, even though we both worked in the same group. Funny how large groups at Microsoft can get...
We had a great Google style lunch at a sunny table in Mountain View. I was too dense to notice that Mark was doing research for his blog. One thing he said got me thinking... Something that many have said over the years, that Microsoft "knows how to ship software".
Being a 16 year Microsoft veteran, a Distinguished Engineer, key architect and code writer for windows, architect of the largest source code control and build system ever attempted, I deeply believed that Microsoft knows how to ship software. We know how to build it, test it, localize it, manufacture it, charge lots of $$$ for it, etc.
Mark and I talked about this briefly at lunch that day, and I have been thinking about it from time to time since...
I am not sure I believe anymore, that Microsoft "knows how to ship software". When a Microsoft engineer fixes a minor defect, makes something faster or better, makes an API more functional and complete, how do they "ship" that software to me? I know the answer and so do you... The software sits in a source code control system for a minimum of two years (significantly longer for some of the early Longhorn code). At some point, the product that the fix is a part of will "ship" meaning that CD's will be pressed and delivered to customers and OEM's. In best case scenarios, the software will reach end users a few months after the Release To Manufacturing (RTM) date. In many cases, particularly for users working in large corporations, they won't see the software for a year or more post RTM...
Consider the .NET framework for a second. Suppose you wrote something innocent like a screen saver, written in C# based on the .NET framework. How would you as an ISV "ship your software"? You can't. Not unless you sign up to ship Microsoft's software as well. You see, the .NET Framework isn't widely deployed. It is present on a small fraction of machines in the world. Microsoft built the software, tested it, released it to manufacturing. They "shipped it", but it will take years for it to be deployed widely enough for you, the ISV to be able to take advantage of it. If you want to use .NET, you need to ship Microsoft's software for them. Isn't this an odd state of affairs? Microsoft is supposed to be the one that "knows how to ship software", but you are the one doing all the heavy lifting. You are the one that has to ship their software the last mile, install it on end user machines, ensure their machines still work after you perform this platform level surgery.
When an Amazon engineer fixes a minor defect, makes something faster or better, makes an API more functional and complete, how do they "ship" that software to me? What is the lag time between the engineer completing the work, and the software reaching its intended customers? A good friend of mine investigated a performance problem one morning, he saw an obvious defect and fixed it. His code was trivial, it was tested during the day, and rolled out that evening. By the next morning millions of users had benefited from his work. Not a single customer had to download a bag of bits, answer any silly questions, prove that they are not software thieves, reboot their computers, etc. The software was shipped to them, and they didn't have to lift a finger. Now that's what I call shipping software.
I would argue that Microsoft used to know how to ship software, but the world has changed... The companies that "know how to ship software" are the ones to watch. They have embraced the network, deeply understand the concept of "software as a service", and know how to deliver incredible value to their customers efficiently and quickly.
We had a great Google style lunch at a sunny table in Mountain View. I was too dense to notice that Mark was doing research for his blog. One thing he said got me thinking... Something that many have said over the years, that Microsoft "knows how to ship software".
Being a 16 year Microsoft veteran, a Distinguished Engineer, key architect and code writer for windows, architect of the largest source code control and build system ever attempted, I deeply believed that Microsoft knows how to ship software. We know how to build it, test it, localize it, manufacture it, charge lots of $$$ for it, etc.
Mark and I talked about this briefly at lunch that day, and I have been thinking about it from time to time since...
I am not sure I believe anymore, that Microsoft "knows how to ship software". When a Microsoft engineer fixes a minor defect, makes something faster or better, makes an API more functional and complete, how do they "ship" that software to me? I know the answer and so do you... The software sits in a source code control system for a minimum of two years (significantly longer for some of the early Longhorn code). At some point, the product that the fix is a part of will "ship" meaning that CD's will be pressed and delivered to customers and OEM's. In best case scenarios, the software will reach end users a few months after the Release To Manufacturing (RTM) date. In many cases, particularly for users working in large corporations, they won't see the software for a year or more post RTM...
Consider the .NET framework for a second. Suppose you wrote something innocent like a screen saver, written in C# based on the .NET framework. How would you as an ISV "ship your software"? You can't. Not unless you sign up to ship Microsoft's software as well. You see, the .NET Framework isn't widely deployed. It is present on a small fraction of machines in the world. Microsoft built the software, tested it, released it to manufacturing. They "shipped it", but it will take years for it to be deployed widely enough for you, the ISV to be able to take advantage of it. If you want to use .NET, you need to ship Microsoft's software for them. Isn't this an odd state of affairs? Microsoft is supposed to be the one that "knows how to ship software", but you are the one doing all the heavy lifting. You are the one that has to ship their software the last mile, install it on end user machines, ensure their machines still work after you perform this platform level surgery.
When an Amazon engineer fixes a minor defect, makes something faster or better, makes an API more functional and complete, how do they "ship" that software to me? What is the lag time between the engineer completing the work, and the software reaching its intended customers? A good friend of mine investigated a performance problem one morning, he saw an obvious defect and fixed it. His code was trivial, it was tested during the day, and rolled out that evening. By the next morning millions of users had benefited from his work. Not a single customer had to download a bag of bits, answer any silly questions, prove that they are not software thieves, reboot their computers, etc. The software was shipped to them, and they didn't have to lift a finger. Now that's what I call shipping software.
I would argue that Microsoft used to know how to ship software, but the world has changed... The companies that "know how to ship software" are the ones to watch. They have embraced the network, deeply understand the concept of "software as a service", and know how to deliver incredible value to their customers efficiently and quickly.
posted by Mark Lucovsky, Software Engineer at 9:38 PM
<< Home